📚 Week 4 · Unit II · Lecture 10
CAMS — Measurement &
Sharing; Config Mgmt

Completing the CAMS framework with the remaining two pillars — Measurement and Sharing — then introducing Configuration Management as the backbone of reproducible, reliable infrastructure.

Dr. Mohsin Furkh DarSchool of Computer Sciences
DateMon, 29 Jun 2026 · 9:00 – 10:00 AM
ProgrammeBTech CSE – Summer Semester
Today's Agenda
1
Recap — Culture, Automation & TDD
2
CAMS: Measurement — Why Data Drives DevOps
3
Key DevOps Metrics & DORA Four Key Metrics
4
CAMS: Sharing — Breaking Down Knowledge Silos
5
Configuration Management — Concepts & IaC
6
CM Tools, Workflows & Key Takeaways
Recap
Where We Left Off
✅
Lecture 9: We explored the first two CAMS pillars — Culture (blameless collaboration, shared ownership, psychological safety) and Automation (what to automate vs. what not to). We then studied Test-Driven Development (TDD) — the Red–Green–Refactor cycle — as a practice where culture and automation meet.
🎯
Today: We complete the CAMS framework by covering the remaining two pillars — Measurement and Sharing. Then we pivot to a foundational DevOps practice: Configuration Management (CM), including Infrastructure as Code (IaC) and popular CM tools.
CAMS So Far (Lectures 9)
  • Culture — blameless, collaborative, shared ownership ✔️
  • Automation — right tools, right tasks, TDD ✔️
  • Measurement — 📍 today's focus
  • Sharing — 📍 today's focus
Why Complete CAMS Now?
  • Without measurement, you can't prove DevOps is working
  • Without sharing, knowledge stays in silos — one departure can cripple a team
  • Configuration Management ties all four CAMS pillars into practice
CAMS — Measurement
The "M" in CAMS: Measurement
📊
Measurement is the third pillar of CAMS — it ensures that DevOps improvements are evidence-based, not gut-feeling-based. Without measurement, you can't distinguish a real improvement from wishful thinking.

If you can't measure it, you can't improve it. Measurement turns opinions into facts and gives teams a shared language for progress.

— Peter Drucker (adapted for DevOps)
🔍
Visibility
Metrics make invisible work visible. How many deployments per week? How long does recovery take? Without numbers, nobody knows.
🎯
Alignment
Shared metrics align Dev and Ops around common goals — not "my code works" vs. "your code broke prod."
📈
Continuous Improvement
Measurement enables the Plan → Do → Check → Act cycle. You check against data, not assumptions.
Measurement Deep Dive
What Should DevOps Teams Measure?

Not all metrics are equal. Focus on metrics that drive behavior — avoid "vanity metrics" that look good but don't improve outcomes.

✅ Meaningful Metrics
  • Deployment Frequency — how often does code reach production?
  • Lead Time for Changes — commit to production time
  • Mean Time to Recovery (MTTR) — how fast do you fix incidents?
  • Change Failure Rate — % of deploys causing a failure
  • Availability / Uptime — SLA adherence
  • Customer Satisfaction — NPS, error rates, user complaints
❌ Vanity Metrics (Avoid)
  • Lines of code written — more code ≠ better code
  • Number of tickets closed — encourages splitting tickets, not real progress
  • Hours worked — promotes burnout, not value
  • Raw server count — more servers ≠ better performance
  • Number of tests — 1000 bad tests are worse than 50 good ones
💡 Key Principle

Measure outcomes, not outputs. The goal isn't "we deployed 50 times" — it's "our users experience fewer errors and faster features." Metrics should answer: "Are our users better off?"

Industry Standard
DORA — The Four Key Metrics

The DevOps Research and Assessment (DORA) team (now part of Google Cloud) identified four metrics that reliably predict software delivery performance. These are considered the gold standard.

DF
Deployment
Frequency
LT
Lead Time
for Changes
MTTR
Mean Time
to Recovery
CFR
Change
Failure Rate
Metric Elite Performers Low Performers
Deployment Frequency On-demand (multiple times/day) Between once/month & once every 6 months
Lead Time for Changes Less than one hour Between one month & six months
Mean Time to Recovery Less than one hour Between one week & one month
Change Failure Rate 0 – 15% 46 – 60%
⚡
Key insight from DORA: Elite teams are not choosing between speed and stability — they achieve both. Speed and reliability are not trade-offs; they reinforce each other when backed by good practices (CI/CD, testing, monitoring, culture).
Measurement Practices
How Teams Implement Measurement
1
Instrument Everything
Add logging, tracing, and metrics collection to applications and infrastructure. Tools: Prometheus, Grafana, Datadog, ELK Stack. Every deploy, every error, every latency spike — capture it.
2
Build Dashboards
Create visible, real-time dashboards that everyone can see — not just ops. Show DORA metrics, error rates, deployment status. "Information radiators" keep everyone honest.
3
Set Baselines & Goals
Before improving, know where you are. Measure current MTTR, deployment frequency, etc. Then set realistic improvement targets: "Reduce MTTR from 4 hours to 1 hour in Q3."
4
Review & Act on Data
Hold regular metric review meetings. Don't just collect data — act on it. If MTTR is high, run a blameless retrospective to find systemic causes and fix them.
📋
Measurement is a feedback loop — it only works if the data leads to action, which leads to re-measurement. Collecting metrics without acting on them is just performance theater.
CAMS — Sharing
The "S" in CAMS: Sharing
🤝
Sharing is the fourth and final CAMS pillar — it closes the loop by ensuring that knowledge, tools, responsibilities, and successes are distributed across the entire team, not locked in individual heads.

Sharing is the loopback in the CAMS cycle. It takes the Culture of collaboration, the Automation you've built, and the Measurement data you've collected — and distributes them so the whole organization learns.

— John Willis, co-creator of the CAMS model
📖
Knowledge Sharing
Runbooks, post-mortems, internal wikis, pair programming — ensure no single person is the only one who knows how something works.
🔧
Tool & Code Sharing
Shared repositories, common libraries, reusable CI/CD pipelines — stop every team from reinventing the wheel.
🏆
Responsibility Sharing
Shared on-call, "you build it, you run it" — developers feel the pain of operations, and ops understands development constraints.
Sharing Practices
How Sharing Works in Practice

Sharing isn't a tool — it's a habit. Here are concrete practices that high-performing DevOps teams use to share knowledge and responsibility.

📝 Knowledge Practices
  • Blameless Post-Mortems — document incidents openly, share lessons company-wide
  • Internal Tech Talks — regular sessions where teams demo their work and share learnings
  • Runbooks & Playbooks — step-by-step guides for common operations tasks
  • ChatOps — run operational commands in shared channels (Slack/Teams) so everyone sees what's happening
  • Pair Programming / Mob Programming — spread knowledge through real-time collaboration
🔄 Feedback Loops
  • Cross-functional Stand-ups — Dev, Ops, QA, Security in the same daily sync
  • Shared Dashboards — same metrics visible to everyone, not just managers
  • Retrospectives — regular team reflections on what went well and what didn't
  • Open Source Inner Model — allow any team member to contribute to any internal project
  • "Game Days" — scheduled chaos engineering events where everyone participates
🔑 The Bus Factor

Sharing directly addresses the "bus factor" — how many people need to get hit by a bus before a project is in trouble? If the answer is "1," your sharing practices have failed. The goal: no single point of knowledge failure.

CAMS Complete
The Full CAMS Framework

With all four pillars now covered across Lectures 9 and 10, let's see how they work as an interconnected system.

CulturePeople & mindset
AutomationTools & pipelines
MeasurementMetrics & data
SharingKnowledge & feedback
🔄
CAMS is a cycle, not a checklist. Culture enables safe automation → Automation generates measurable data → Measurement reveals what to share → Sharing strengthens culture. Each pillar feeds the next.
🎭
C → A
A blameless culture gives teams the psychological safety to experiment with automation — failures are learning, not career risks.
⚙️
A → M
Automated pipelines produce rich data — build times, test pass rates, deployment frequency — that feeds measurement naturally.
📊
M → S
Measured results need to be shared via dashboards, retros, and reports — otherwise data sits in a silo and never drives improvement.
🤝
S → C
Sharing learnings and responsibilities builds trust, empathy, and ownership — which strengthens the culture for the next cycle.
Configuration Management
What Is Configuration Management?
🖥️
Configuration Management (CM) is the practice of systematically handling changes to a system's configuration — so that it maintains integrity over time. In DevOps, CM ensures that every server, service, and environment is set up consistently and reproducibly.
❌ Without CM (Manual Setup)
  • Servers are configured by hand — each slightly different ("snowflake servers")
  • "It works on my machine" is a constant problem
  • Rebuilding a crashed server takes hours/days of detective work
  • No record of who changed what, when, or why
  • Environment drift — staging doesn't match production
✅ With CM (Automated & Versioned)
  • Every server is built from the same code/recipe ("cattle, not pets")
  • Environments are identical — dev, staging, prod all match
  • Rebuilding a server = re-running the CM script (minutes, not days)
  • All changes are versioned in Git — full audit trail
  • Configuration drift is detected and auto-corrected
🐄
Pets vs. Cattle: In the old model, servers were pets — unique, lovingly maintained, irreplaceable. In the CM model, servers are cattle — identical, numbered, and if one goes down, you replace it instantly with an identical copy.
Core Concept
Infrastructure as Code (IaC)

IaC is the practice of defining and managing infrastructure through machine-readable definition files, rather than manual processes or interactive tools.

📄
Declarative Approach
You describe the desired state ("I want 3 web servers with Nginx"), and the tool figures out how to achieve it. Examples: Terraform, Ansible, Puppet.
🔁
Idempotent
Running the same configuration multiple times produces the same result. No surprises — apply it once or ten times, the outcome is identical.
📂
Version Controlled
Infrastructure definitions live in Git alongside application code. Review changes via pull requests, roll back by reverting a commit.
# Example: Ansible playbook to install and start Nginx
---
- hosts: webservers
  become: yes
  tasks:
    - name: Install Nginx
      apt:
        name: nginx
        state: present

    - name: Start Nginx service
      service:
        name: nginx
        state: started
        enabled: yes
💡 Why IaC Matters

IaC brings the same rigor to infrastructure that source control brought to application code: reproducibility, auditability, and collaboration. It's the bridge between the "A" in CAMS (Automation) and Configuration Management.

CM Tooling
Popular Configuration Management Tools

No single tool fits all scenarios. Here's a comparison of the most widely used CM tools in the DevOps ecosystem.

Tool Approach Language Key Strength
Ansible Agentless (SSH) YAML Simple, easy to learn, no agent needed on target machines
Puppet Agent-based Puppet DSL Mature, strong for large-scale enterprise environments
Chef Agent-based Ruby DSL Highly flexible, code-driven "recipes" and "cookbooks"
Terraform API-driven HCL Cloud infrastructure provisioning (AWS, Azure, GCP)
SaltStack Agent or SSH YAML High-speed execution, event-driven architecture
Provisioning vs. Configuration
  • Provisioning — creating resources (VMs, networks, databases). Tools: Terraform, CloudFormation
  • Configuration — setting up what's inside (packages, files, services). Tools: Ansible, Puppet, Chef
  • Often used together: Terraform provisions the VM, Ansible configures it
Push vs. Pull Model
  • Push — controller sends config to nodes (Ansible, SaltStack SSH)
  • Pull — agents on nodes poll a central server for updates (Puppet, Chef)
  • Push: simpler, immediate. Pull: better for large fleets, auto-healing
Workflow
Configuration Management Workflow

Here's a typical CM workflow showing how infrastructure changes flow from a developer's laptop to production.

Write ConfigDefine desired state
Version ControlGit commit & PR
Code ReviewPeer review config
TestValidate in staging
ApplyDeploy to production
1
Write Configuration Code
Developer writes the desired state of infrastructure as code — e.g., an Ansible playbook, a Terraform plan, or a Puppet manifest. This defines packages, services, files, and permissions.
2
Commit & Push to Git
The configuration file is committed to a Git repository and a pull request (PR) is created, just like application code. This provides version history and audit trails.
3
Peer Review & Approve
Team members review the proposed changes — catching errors, ensuring compliance, and verifying the intent. This is where "Sharing" meets CM.
4
Test in Staging
Apply the configuration to a staging environment first. Run automated tests to verify the desired state is achieved without breaking anything.
5
Apply to Production
After staging validation, the same config is applied to production. Because the code is idempotent, re-applying it won't cause side effects.
Summary
Key Takeaways — Lecture 10

Today we completed the CAMS framework and introduced Configuration Management as a foundational DevOps practice.

01
Measurement (M)DevOps teams measure outcomes, not outputs. DORA's four key metrics — DF, LT, MTTR, CFR — are the industry gold standard for performance assessment.
02
Sharing (S)Knowledge, tools, and responsibilities must be distributed across the team. Post-mortems, runbooks, ChatOps, and shared on-call prevent single points of knowledge failure.
03
CAMS as a CycleCulture → Automation → Measurement → Sharing form a reinforcing loop. Each pillar feeds the next — CAMS is a system, not a checklist.
04
Configuration ManagementCM eliminates "snowflake servers" through versioned, automated, idempotent configuration code — turning infrastructure into "cattle, not pets."
05
Infrastructure as CodeIaC brings version control, code review, and reproducibility to infrastructure — bridging the gap between Automation and CM.
06
Next: Lecture 11Infrastructure Automation, Root Cause Analysis, Blamelessness, and Organizational Learning — taking CM and CAMS into deeper operational practice.
🎯
Exam tip: Be able to explain all four CAMS pillars with examples. Know the DORA four key metrics and the difference between elite vs. low performers. Understand "pets vs. cattle" and why IaC uses declarative, idempotent code.